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1 Introduction 


1.1 Is automatic program verification important? 

Program verification is a critical problem in computer science. Many believe that man- 
ual, informal verification is acceptably reliable and more practical them automatic formal 
verification. However, verification of distributed programs is difficult to achieve manually. 

Consider the following simple distributed algorithm. Pi and P2 are two processes that are 
executed on a processor. They share a common variable t, and each has a local variable 
yi,i — 1,2 that can be read by the other process. We assume that at each step exactly 
one process is active, i.e., it executes the current statement. Pi and P2 share a common 
resource (printer or disk) and the algorithm is meant to guarantee that at most one process 
uses the resource at a given time. We say that the process is in the critical section when 
it uses the resource. £3 and M3 are the critical sections for P\ and P2, respectively. 

The reader is challenged to verify whether the following algorithm satisfies two properties: 


1 . “Mutual exclusion” is guaranteed: it is never true that Pi is at £3 and P% is at M3. 

2 . Liveness is guaranteed: always if P x (P 2 ) is at L\ (Mi) (requesting the resource), 
then eventually Pi (P 2 j will be at £3 (M3) (getting the resource). 


DECLARE t : [0..1]; 

INITIALLY t = 1 ; 


PROCESS Pi 


DECLARE y x : [0..1]; 
INITIALLY yi = 0; 

£0 : goto £ 0 ; I {<:=!; goto £ 1 ; } 


£1 : yi := 1; 

£2 ■ if (y 2 = 0 V t = 0) goto £ 3 ; 
if (y 2 = 1 a t = 1) goto £2; 


critical section £3 : yi := 0; goto £<>; 

END 


II 

PROCESS P 2 


DECLARE y 2 : [0..1]; 
INITIALLY y 3 = 0; 
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Mo : goto Af 0 ; | {< := 0; goto M \\ } 
M x : j/a := 1; 

M^ : if (l/i = 0 V t = 1) goto M 3 ; 
if ( 1/1 = 1 A t = 0) goto Ma; 


critical section M 3 : j /3 := 0 ; goto Mo ; 
END 


1.2 How to verify it automatically 

Program verification is defined as follows: given an implementation A and a specification 
0, does A satisfy 0 ? Putting this into more formal terms, in the most general case, 
program verification is equivalent to the problem of checking if L\ CI 2 , where L\, La are 
two languages defined by Turing machines. Hence, in the most general case the verification 
problem is undecidable. 

Programs, however, have been verified manually. Manual verification is sometimes mis- 
leading and almost always very tedious, especially in the case of parallel or distributed 
programs. Some systems designed to support formal, manual verification have been devel- 
oped in the last few years. For example, Crawford and Goldschlag provide an interactive 
theorem prover to support the verification of distributed systems ([CG87]). Theorem 
provers provide only a partial and most often not satisfactory answer to the problem. 

Taking a different approach, Clarke et al. [CES83] suggested that by focusing strictly 
on finite state programs, one could provide a fully automatic verifier that would still be 
applicable to such domains as communcation protocols and cicuit design. In [CES83] an 
algorithm for checking a finite state model against a property specified by Computation 
Tree Logic (CTL) is provided. The algorithm is linear in the size of the model and the 
property. The algorithm was implemented [B86, BC86], and was proved to be useful for 
verifying circuit design. However, the CTL formalism is not always enough to express 
properties of distributed systems [L80, EH86]. Linear Temporal Logic (LTL), on the 
other hand, seems to provide the required expressive power at the cost of having a model 
checking problem, which is NP-complete [SC82]. 

Thus, the linear temporal logic advocates claim to have the required expressive power 
while those in favor of branching time claim to be “efficient”. In [LP85] an 0(\M\2^) 
algorithm for checking a finite state model M against a linear temporal logic formula p is 
described. It is claimed that since the property is usually small and the worst case rarely 
happens, the algorithm is “practically efficient.” Branching Time “struck back” in [EL85], 
where it was shown that any model checking algorithm for LTL implies an algorithm of 
the same complexity for CTL*, the extended version of branching time temporal logic, 
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which subsumes both LTL and CTL. 

In this work, we provide evidence to support the claim that model checking for LTL is 
“practically efficient.” 

We describe two implementations of a linear temporal logic model checker. One is based 
on transforming the model checking problem into a satisfiability problem. The other 
checks an LTL formula for a finite model by computing the cross-product of the finite 
state transition graph of the program with a structure containing all possible models for 
the property. We experimented with a set of mutual exclusion algorithms and tested 
safety and liveness under fairness for these algorithms. We believe that the measurements 
we have done for these examples provide experimental evidence for the practicality of 
model checking of linear temporal logic formulae. 

Section 2 provides the syntax and semantics of linear temporal logic. Section 3 provides 
a detailed example of a finite state concurrent program and expresses safety and liveness- 
under-fairness properties for this program, in LTL. Both implementations are based on 
the tableau algorithm described in Section 4. Section 5 discusses the basic ideas behind 
the two different model checking algorithms. Section 6 provides more details regarding 
the implementations and experimental results. 


2 Linear temporal logic 

A temporal logic formula is defined over a set $ 0 of atomic formulae, using the boolean 
operators V and -i and the temporal operators next (O) and until (U). A model for 
a temporal formula p is an infinite sequence of states <r : so,Si,..., and a mapping 
t : {s, | z > 0} — *■ 2 *° assigning to each state s< the set of atomic formulae that axe true 
at this state. 

$ denotes the set of all temporal formulae that are inductively constructed from $ 0 as 
follows: 

if P € then P 6 $ 

if p, q € $ then ip and p V q € $ 

if p, q € $ then O P € $ and pUq € $ 

For a given model a and a temporal formula p, we say that ( cr,j ) satisfies p, denoted by 
(<T,j) \= p, if p is evaluated to true on the jth state of a. 

Formally: 

(<7 ,j) P, for P G $o iff P is evaluated to true in Sj by the mapping r, that is, if 

P € t(sj) 
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M) N -’P iff (*>i) £ p 

(<r, j) h= P V q iff (cr,j) h p or (a, j) b q 
M) f= Op iff (°J + !) N P 

(o,j) \= p Uq iff there exists * > j such that (<r, t) h 9 and f° r all k, j < k < i , (<r, k) |= p 

We use the following operators as abbreviations: 

and: p Aq = ~<(~'P V ~<q) 
implies: p — ► q = ->p V g 
equivalent: p = q = {p —* q) h(q —* p) 

eventually: Op = TWp, (cr,;) f= Op if for some i > j, (a, i) f= p. 
always: 'Ip = ~>0->p y f= Op if for all t > j, (<r, t) p. 

A model <7 satisfies p if (<7, 0) satisfies p. 

A formula p is satisfiable if there exists a model that satisfies p. 

A formula p is va/td if for every model a, a satisfies p. Hence, a formula p is valid iff ->p 
ib not satisfiable. 

The temporal formalism is used to specify properties of finite state programs. A program 
is defined as the set of all possible computations. A computation of a given program is 
a sequence of states, starting from the initial state, where each state is defined by an 
assignment of values to all program variables. A computation can be viewed as a model 
for a temporal logic formula. A program satisfies a property p, if for every computation 
<r of this program, <7 satisfies p. 

For linear temporal logic, the model checking problem is stated as follows: given a finite 
state transition graph M = (N,E,r), where r is a special root node (the initial state), 
a mapping function ir : N -* 2*° assigning atomic propositions to states, and a linear 
temporal logic formula p, does every path of M initiated at *• satisfy p? 


3 Example 

To demonstrate the terms and notation, we give an example of a distributed program and 
some properties that this program is required to satisfy. 

We distinguish between two types of program properties, safety and liveness. Safety 
properties state that nothing “bad” happens throughout the computation, while liveness 
properties state that something “good” eventually will happen during the computation. 
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We assume an asynchronous semantics, meaning that the set of all program computations 
consists of all possible interleavings of process computations. 

Peterson’s Mutual Exclusion Algorithm 


DECLARE 


t : [0..1]; 

INITIALLY 


t = l; 

PROCESS Pi 




DECLARE 

yi : [0..1] 


INITIALLY 

Vi = 0; 


L 0 : goto L 0 ; | {yi := 1; goto L \\ } 
L x : t := 1; 

L 2 : if (j/2 = 0 V t = 0) goto L 3 ; 
if (y 2 = 1 A t = 1) goto L 2 \ 

critical section L 3 : yi := 0; goto Lo\ 

END 


PROCESS P 2 

DECLARE y 7 : [0..1]; 

INITIALLY y 2 = 0; 

M 0 : goto M 0 ; | {y 2 := 1; goto M x ; } 

Mi : t := 0; 

M 2 : if (y x = 0 V t = 1) goto M3; 
if (yj = 1 A t — 0) goto M 2 \ 

critical section M 3 : y 2 := 0; goto M 0 ; 

END 


t is a global variable and y x and y 2 are local variables of Pi and P 2 , respectively. All 
variables are of type integer with range [0..1]. Al! statements appearing under the same 
label are assumed to be one atomic statement, i.e. nothing is interleaved between them. 
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Since each process has four possible locations we can view each program counter as a 
variable with range [0..3]. To describe the program computations we transform each 
program variable into a set of propositions, standing for the bit representation of the 
variable. We use f,yi and y? as propositions to represent the corresponding variables. 
P lo , Pi,, P20 and Pi, are used to represent the program counters of P\ and P2, respectively. 
In the initial state of the program, t = 1 , 3/1 = 0, y 2 = 0 and P\ and P 2 are in L n and Mo, 
respectively. Hence, for all program computations, t is true and yi,y2,Pi 0 ,Pi,, Pi 0 and 
P2, are false in the first state of the computation. From this initial state there are four 
possible transitions: 

1. P\ executes the statement “goto L 0 " , resulting in the same state. 

2. Pi executes the statement “3/1 := 1; goto Li”, resulting in a state where t,yi and 
Px 0 hold and y2,Pi,,P2 0 and P 2 , are false. 

3. P 2 executes the statement “goto Mo”, resulting in no change in state. 

4 . P2 executes the statement “y 2 := 1 ; goto Mi”, resulting in a state where t,y 2 and 
P2 0 hold and y\ Pi, and P 2 , are false. 


The construction of the global transition graph of the program proceeds in this way. Since 
the number of variables and the range of each is finite, there are only a finite number of 
different states. 

The safety property that we want to check for this algorithm is that it really guarantees 
mutual exclusion, i.e., it is never the case that Pi is in L3 and P2 is in M3 at the same 
time. Hence we want all program computations to satisfy 

D_, (A 0 A Pi, A P 2o A P 2 , ) 

The liveness property is that each of the processes-if it is not idle forever (i.e., at Z, 0 or 
Mo)- eventually gets to execute its critical section. Hence, we want all program compu- 
tations to satisfy 


D ((A 0 A -■Pi, V ->Pi 0 APj,)-* 0(P i 0 A Pi,)) 


and 


D ((^2o A -'P 21 V — 'Pij, A P 2 , ) — ► 0(P2o A P 2 , )) 


Often, we want to verify that the program satifies these properties under some fairness 
condition, to exclude those executions in which one of the processes is not active from 
some point on in the computation. For example, we may want to consider the above 
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properties under the assumption that each process executes infinitely many transitions. 
It is rather clear that Peterson’s algorithm above does not satisfy the liveness property if 
we do not assume such fairness. To specify those computations that satisfy the require ’ 
fairness condition, we use an additional proposition. The proposition pi will hold only in 
these states in which Pi is active; namely, only Pi can execute a transition from a state in 
which pi is true. Thus, we have now two different initial states, one in which pi holds and 
one in which ->p\ holds. Each of these states has four possible next states, resulting from 
the two transitions the active process can take and the two alternatives for the next active 
process. To specify the liveness property above, under fairness, we use the following: 

□ (Op, A 0(-p,)) -» □((P, 0 A -P,, V -P, 0 A P„) - O(P l0 A P,J) 


4 The tableau algorithm 

The satisfiability problem for temporal logic formulae is NP-complete. In the worst case, 
the number of steps needed to decide if a given formula p is satisfiable is 0(2^1). The 
tableau algorithm for checking the satisfiability of a linear temporal formula [PS81] is 
aimed at avoiding the exponential worst case, when possible, by generating only those 
states that are necessary. The algorithm consists of two parts: 

1. Given a formula p, a directed graph M p = (N p , E p , r) is constructed, and a set jr(n) 
of atomic propositions is associated with each node n in N. This graph is “locally 
consistent” in the sense that for each node n, the set of formulae x(n) is consistent 
for all formulae except for path formulae involving O and U. 

2. Checking global consistency: for each node n £ N p and for each fom la O p,qUp in 
7r(n), check if there exists a path from n that eventually satisfies q. 

In the following, we assume (without loss of generality) that all paths in the model are 
infinite. We can assume that the formula to be checked is of the form p A DT. 


4.1 The construction part 

We distinguish between two types of formulae called a and formulae. 

q formulae are those that can be expressed by a conjunction of their subformulae, e.g., 
□p = p A O 1 - 1 ?- 1° Ihe construction procedure an a formula r is replaced by the set of its 
subformulae, denoted a(r), as follows : 
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r 

a(r) 

P A ? 

{P.?} 

□p 

{p. O d p} 

“•(P v <l) 

{~*P» -l) 

“■(P “♦ 9) 

{p> ^9) 

■•(Op) 

{°bp)l 

^(□p) 

{0(— >p)} 


0 formulae are those that can be expressed as a disjunction of their subformulae, e.g., 
Op = p V OOp- hi the construction, procedure a node with a 0 formula r is replaced 
by two nodes, each containing one of the sets of subtormulae, denoted 0i(r), 0i{r) and 
defined as follows: 


r 

A(r) 

A(') 

pv? 

{P> 

{9) 

P -4 9 

{-P} 

{9} 

P = 9 

{P»9} 

{“•P, ^9} 

pUq 

{9} 

{p.O(p ^9)} 

Op 

(P) 

(OOp) 

~ *(P A 9) 

{“•P) 

{■•9} 

“•(P = 9) 

{~ *P» 9} 

{p, ^9} 

"•(P ^9) 

{ d ( _, 9)} 

{(“*9 W(->pA-*g)} 


To describe the construction algorithm, we define for a set of formulae <f>: 

The set next(^) is the set of formulae that must be true in a successor of any state that 
satisfies all p € 4>. 

next(^) = {q \ Oq € 

The set basic(^) is the subset of <f> that uniquely identifies a state satisfying all p 6 

basic(^) = {p \ p € ^ and (p is atomic or p = 0?)} 

The function annlyze(^), provides for a set of formulae <f>, a set 5 of sets of formulae 
resulting from repeated applications of a, 0 rules to formulae in <f>. The function analyze 
is used to construct M p = (N p , E p ), as follows: 

construct (p) 

start with root r,jr(r) {p}, N p = {r},E p = 0. 

S =analyze(z(r)) 
for ^ € 5 

if basic(^) = basic(ir(n)) for some n € N p 
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add (r, n) to E p 
else 

add a new node n to N p , with t ( n) = <f> 
add (r, n) to E p 
for m G N p a leaf in (X p , £ p ) 

S = analyze(next(7r(m))) 
for 0 € 5 

if basic(<£) = basic(7r(n)) for some n € N p 
add (m, n ) to E p 
else 

add a new node n to N p , with ir(n) = <f> 
add (m,n) to E 

end construct 

The function analyze is formally defined as follows : 


analyze(</ 0 ) 

X:=U*o,0)} 

for (q>. <p) G X with 0^0 

X := X - {{+,*)} 

if p G <t> 

if p is an q formula 

4>:=(4>- {p}) U {q | q G a(p) and q £ <p} 
:= U {p} 

X:=XU {(*,*)} 
if p is a /? formula 

4>\ := ( <t> ~ {p}) U {q | q G /?i(p) and q $ <p} 
<£2 := ( 4> ~ {?}) U {q j q G /? 2 (p) and q # <p} 
:= <p U {p} 

X := X U {(^i,<p),(^ 2 ,<p)} 
if p is an atomic formula or p = Q q 
<f>-=4>- {p} 

<P := <pU {p} 

X:=XU {(^,<p)} 

5:=0 

for (0,<p) G X 

if there is no q, ->q G <p 
S:=S U {<p} 
return (5) 
end analyze 
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4.2 Checking eventualities 


When the construction of the structure (7V P , E p ) is completed, each node in the graph is 
locally consistent, but we still have to check for global consistency. That is, we have to 
check that each node satisfies the following two properties: 

1. the node has at least one successor. 

2. for each formula of the form Op or q Up in the set of formulae 7r(n) of a node n, 
there exists a path leading from n to a node m, such that p € x(m). 

Each node that does not satisfy these two properties is removed from the graph. The 
formula p is satisfiable if and only if the remaining graph contains the root node r. 

[LP85] shows that when checking temporal consistency it is enough to check consistency 
in the strongly connected components of the graph. 

A strongly connected component (SCC) in a directed graph is a maximal set of nodes of 
the graph such that there is a path between each pair of nodes in the set. 

We say that a SCC ( N ', E') is consistent in a model M, if for every n € N 1 and every 
Op,qUp € x(n) there exists m € N* with p € x(m), and if N ' contains a single node n, 
then there exists some successor of n in M. 

check (Np, E p ) checks temporal consistency in the locally consistent model M p : 
check(Ap, E p ) 

find strongly connected components in (N p , E p ). 

For G a leaf SCC in ( N p , E p ) 
if G is consistent 
stop 
else 

remove G from (N pt E p ) 
p is satisfiable iff r € N p 
end check 

If p is satisfiable, then a model can be constructed from the the graph (N p , E p ). For every 
node n € N p and every Op or qUp in x(n) we know that there exists a path from n leading 
to a node m such that p € x(m). However, we have to construct one infinite path, starting 
from root such that for all nodes along the path, all formulae will be satisfied along this 
path. The following procedure, build-model, defines such an infinite path. Note that ; 
(the semicolon) here denotes concatenation. 

build_model(JVp, E p ) 

S(n) denotes the ordered list of successors of a node n. 


10 



n := r 
a :=n 
while (true) 

m := head of tf(n) 

<r := a; m 

6(n) := tail(6(n));m 
n := m 

end buildjnodel 


The tableau algorithm for checking satsifiability of a temporal formula p is composed of 
the following steps: 

1. construct(p) to get the structure M p = ( N P ,E P ) 

2. check (N P ,E P ) 

3. if r € N p 

p is satisfiable 
else 

->p is valid 


In the worst case, the size of M p is 0(2^). 

5 The satisfiability approach vs. the model check- 
ing approach 

Given a finite state program A, a property p and fairness condition F, our goal is to 
verify whether every fair (according to F) execution of the program satisfies p. Two basic 
approaches to this problem are described here. One is to construct a formula <j>(A,F,p) 
consisting of the possible transitions that can be executed by the different processes, the 
fairness condition and the property p, such that ~><f>(A, F, p) is valid iff A satisfies p under 
F. The other approach is to construct the transition graph for the program A, and check 
if F — ► p is satisfied along every possible execution path in the transition graph. 


5.1 Verifying by checking satisfiability 

We are given a program A , composed of n processes Pi, Pi,. . . , P n , a property p, and 
fairness condition F\ we wish to verify that any possible interleaving execution of the 
processes that satisfies F satisfies p. 
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To verify that A satisfies p under F: 


1. For a given algorithm A, a property p and ieirness condition F, construct the 
temporal formula <j>(A,F,p). 

2. Use the tableau algorithm to check satisfiability of <f>(A, F,p). 

3. A satisfies p under F if and only if the tableau algorithm terminates with F, p) valid. 

4>{A, F,p) is of the form 


M.A.F,,) = -((/ A a(V »(«))) - (F - p)) 

1=1 

/ specifies the initial state, and 0(P,) specifies the transitions that can be executed by 
process jP;. If <f>(A, F,p ) is satisfiable, then there exists a model whose initial state satisfies 
/, each of the model transitions from one state to the next corresponds to one of the 
possible processes transitions specified by 0(P),t = 1, . . . ,n, and the model satisfies the 
fairness condition F , but it does not satisfy p. This implies that this model describes a 
fair execution of the program that does not satisfy the required property; hence, A does 
not satisfy p. If <f>(A,F,p) is not satisfiable it means that ~'<f>(A, F,p) is valid, hence any 
model corresponding to a program execution specified by / A □(V"_ 1 0(P,))) that is a fair 
execution (i.e., satisfies F) must also satisfy p, hence A satisfies p under F. 

To be able to specify fairness, we use for each process a proposition p,-, which must hold 
in every state where process p is active. The general form of 0(P,), is 

m 

Pi A p(P.) A ( \/ t k ) 

k=l 

where {tk \ k = 1, . . . ,m} stand for the set of transitions that can be executed by P,- and 
p(p) guarantees that when P is active it can not change the values of any variable that 
i° a local variable of another process. p(P.) haw the form 

A A ( x = O) 

i*' x variable of p } 

Note that the set of local variables of a process include the program counter for this 
process. 

Each of the t m is specified by a formula that is a conjunction of two parts. The first 
part specifies the current state, which includes the program counter value and a condition 
stating some values of some variables. The second part specifies changes of values in the 
next state resulting from executing the transition: change of program counter and change 
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of variables by an assignment statement. All other local and shared variables are not 
changed. 

To demonstrate how <f>(A, F,p) is constructed, we now define the parts of the formula for 
Peterson’s mutual exclusion algorithm. 

I = ->Pi 0 A -•Pi, A ~'P io A -iP 2l A / A ->yi A ->y 2 

For process P\\ 


f*(Pi) = (Vi = OVi) A (P 2o = OP2 0 ) A (P 2 , = 0 p 2, ) 
t\ = ->Pi 0 A --Pi, A 

{O^Pio A O^Pu A (yi = Oyi) A (t = O t) V 

O p io A O-'Pu A Oyi A {t = O t)) 

t\ = P lo A-Pi,A 

O -'Pio A O p u A (yi = Oyi) A O* 
t\ = -P l0 A P u A (-y 2 V -if) A 

O-Pio A A (yi = Oyi) A (t = O0 
<4 = “'Ao A Ai A (y 2 A t) A 

O-A. A OA, a (yi = Oyi) a (/ = O 0 

t\ = PioAPx, A 

O-Ao a O^-Pi! a o-yi a (< = O0 


Hence 

B(Pi) = Pi A /i(P0 A (fj V V V fl V tj) 

For process P 2 : 


a*(A) s (yisOyi) A (A. = OA.) A (A.=OAi) 

t\ = -’P 2o A ~’P 2 , A 

(O^Pio A O -1 ^, A (y 2 = Oy>) A (t = OO V 
OPio a O^Pi, a Oy2 a (< = OO) 

< 2 = Pio A -iP 2 , A 

O^Pio A OP2, A (y 2 = Oy2) A 0 -1 * 
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t\ = ->P 2o A P 2 , A (“>yi V t) A 

O-P 20 A 0^2i A (y 2 = Oy 2 ) A (t = Qt) 

1 1 = “'Pic A P 2l A (y x A -><) A 

O-'Pio A OPii A (y 2 s= O 2 ) A (t = OO 
*5 = P20 A P 2 , A 

Q-'Pto A Q-'ft, A O -1 ^ A (t = Qt) 


Hence 

0(P 2 ) = p j A p(P 2 ) A (<? V V <1 V t\ V t*) 

A fair execution is an execution in which each process is active infinitely often, specified 
by □(Opi A Op,). 

It follows that in order to check safety of the Peterson mutual exclusion algorithm under 
fairness, we have to check satisfiability of the formula 

-((/ A U{9{P X ) V 0(P 2 ))) -> (□(Op! A Op,) - □(-.(P l0 A P u A P, 0 A P 2l )))) 
and to check liveness 

-((/ A D(*(A)V «(/%)))- 

(□(Opt A Op,) - □((-P l0 A P u V P l0 A -P Xl ) - O(P l0 A P Xl )))) 

Since checking satisfiability is exponential in the size of the formula that is checked, using 
the formula <f>(A,F,p) to check if A satisfies p may be, in the worst case, exponential in 
the length of the program plus the size of the property. 


5.2 Verifying by model checking 

In the model checking approach, the transition graph of the program is constructed and 
then it is checked to determine if there exists a path in the graph that satisfies ->(F — ► p) 

1. Construct the global transition graph ( S,T)a for the program A. 

2. Use construct (-‘(F — ► p)) to construct a structure M-,(p-*p) = (AT, E). 

3. Cross product M-,(p-*p) an d ( S,T)a to get a locally consistent structure, denoted 
(V, R)(a,f,p)i with a root node denoted v 0 . 

4. check(( V, R)(a,f,p)) 

5. A satisfies p under F if and only if v 0 £ V. 
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If uo G V after check((V, R)(a,f, p )), then the remaining structure contains a path corre- 
sponding to a possible execution of the program A, and this path satisfies the formula at 
the root of (N, E)-,(p^ p ), that is, it satisfies ->(F —* p). Hence, there exists an execution 
that satisfies F but does not satisfy p. This implies that A does not satisfy p under F. 
If v 0 is deleted from V, then there does not exist a path in the transition graph that 
satisfies -<(F — > p), hence every execution of the program A that satisfies F satisfies p. 
This implies that A satisfies p under F. 


5.2.1 Constructing the global transition graph 

The global transition graph consists of the set of nodes S and the set of edges T. Each s G 
S stands for a program state and a set 7r(s) of propositions and negations of propositions 
is associated with it. The set x(c) provides the value of the program variables in the state 
s, by the corresponding propositions. In each state s, exactly one process Pi is identified 
as active, by setting the corresponding p; to true and pj for all j ^ i to false. The 
construction of the graph starts with a special root state s 0 such that 7r(so) corresponds 
to the values of program variables at the initial state, so has n successors, where successor 
i corresponds to the initial state with process i active, i.e., p t - is true. The construction 
of the transition graph proceeds by generating transitions from each state, according to 
the statements that can be executed from the state by the active process, and creating 
states corresponding to the resulting program state with one of the processes being the 
next active process. Since the program is finite state, the transition graph construction 
must terminate. 

5.2.2 Cross product of the two structures 

The cross product procedure is defined by taking those pairs (n,s), n € N and s G S, 
which are consistent. A pair (n, s) is consistent if and only if for every atomic formula 
P, at most one of P,~>P is in 7r(n) U 7r(s). V is initialized to u 0 corresponding to the 
pair (r,s 0 ), that is, 7r(v 0 ) = 7r(r) U 7r(s 0 ). R is initialized to the empty set. (V,R)^a,f,p) is 
constructed by cross-product. 

cross_product(( N, E, r), (5‘, T, s 0 )) 

start with root v 0 ,ir(v 0 ) := w (r) U 7r(s 0 ), V := {v 0 },E := 0 
for v € V a leaf in (V, R ) 
for m G N, (n, m) € E 
for t G S, ( s,t ) G T 
if ( m,t ) is consistent 

if for some u G V basic(u) =basic(7r(m)) U tt(<)) 
add (v,u) to R 
else 
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add a new node u to V with ?r(ti) = ir(m) U 7r(/) 
add (v, u) to R 

end cross_product 


6 Implementation and experimental results 

6.1 Implementation of the tableau algorithm 

Several issues seemed to be vital to an efficiert implementation of the tableau algorithm. 

6.1.1 The form of the LTL formula 

1. Conjunctive form has an advantage over disjunctive form. A disjunctive form of 
a subformula specifying a transition in the program is: p, Ac, — ► Qq t > where 
p, and c, specify the current program counter and a condition, respectively and q,> 
specifies the next state. The program is specified by the conjunction of all disjunctive 
formulae specifying transitions. An equivalent specification for the program is by 
disjunction of all transitions specified in conjunctive form by p, Ac, A Qq,' (see the 
formula in Section 5.1). The implementation of the tableau algorithm was faster for 
the conjunctive form, probably because of the priority we give to rules applied to a 
formulae (see Section 6.1.3.). 

2. Putting the “next” operator (O) as “low” as possible turned out to be more efficient 
tnan an equivalent form in which next operators appeared before A, V or -> operators. 


6.1.2 Representation of sets of formulae 

Each node in the constructed graph is associated with a set of formulae. The set of all 
possible subformulae of the formula to be checked is computed (the size of the set is at 
most 5|p| for a formua p) and the formulae are numbered. A set is represented by an 
array of bits, where the tth bit is 1 iff the tth formula is in the set. This representation 
allows operations such as union, checking consistency of a set, checking membership, etc. 
to be performed efficiently by bit operations. 

6.1.3 Application of a,/? rules 

In the construction procedure, the same rule may be applied to the same formula many 
times. To avoid some of this duplication, a rules should have prioprity over 0 rules, as 
the following shows. Consider <f> — {91,92, • • • , 9*}, a set of formulae where 91 is an a 
formula and 92 is a 0 formula. If we first apply the 0 rules to 92, we have two nodes 
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associated with fa = {91, faiqi), ...,<?*} and fa = {91, £2(92)* •••»?*}• Thus, the rules for 
91, 93? • • • > 9fc must be applied at least twice. Applying the a ride for qi in <p will result in 
a set {a(qi),q2,...,qk}- 

To try to minimize duplicate applications of the same rule to the same formula, we 
construct, in a preprocessing procedure, a table T, providing the results of repeated ap- 
plications of a rules to subformulae. The set of subformulae CL(p) is computed. For each 
q ECL(p), the set a(<jr) or the sets fa(q), fa(q) resulting from applying the corresponding 
rule for q are stored in Tfg], the entry corresponding to q in the table T. Then, the a 
closure of T is computed by repeatedly applying a rules to eac^ set tf> in the entry T[q] in 
the table. A set <f> is a closed if for every a formula q € fa a{q) Q <f>. a rules are applied 
to sets in the table until each set ^ is a closed. In the construction algorithm, a rule is 
applied to formula q in a set 4 > by replacing ^ by <f> U if> for each if> in T[q]. 

6.1.4 Search of nodes in the graph 

With the generation of a set <f> the graph is searched to find if there exists a node n 
such that basic(7r(n)) = basic(^). To enable an efficient search we interpret the binary 
representation of a set tt(m) as a number that is used as a unique id of the node n. The 
ids are hashed (see [K 73 ]) into a table of size K, such that on the average entry i in the 
table will have a list of \N P \/K nodes. Hence, to search the graph for the set basic(^), 
we search the nodes in the entry corresponding to basic(^) in the hash table. 


6.2 Implementation of the model checker 

The implementation of the construction of the global transition graph uses ideas similar 
to those described above. States are represented by the set of propositions and negation 
of propositions that hold in the state. When the cross product with the model M p is 
computed the resulting structure is composed of nodes each of which is a pair of pointers 
(Ps,Pn) where p t is pointer to a state in the global transition graph and p n is a pointer to 
a node in the model. The set associated with (p«,p n ) is x(s) U 7r(n) . 


6.3 Experimental results 

In the current implementation the model checking approach was up to 10 times faster 
than the satisfiability approach. The following results were measured on a SUN 4 for 
two mutual exclusion algorithms Xi and Xi (see Appendix) X\ is a mutual exclusion 
algorithm for n processors that guarantees safety and communal liveness but not liveness. 
Communal liveness , in this case, means that if some process is asking to use the resource, 
then eventually some (not necessarily the same) process will get to execute its critical 
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section. Algorithm X 2 is a more complicated mutual exclusion algorithm. It guarantees 
safety and liveness for n processors. 

Each row in the table provides execution time in seconds and the number of nodes in 
the locally consistent structure. The results relate to the verification of the program 
composed of n processes of algorithm Xi or X 2 (in the first column) when checked against 
the property in the second column. 

Note that some results are missing for the model checking program. This is because the 
current implementation (to be corrected in the near future) of the compiler requires a lot 
of manual preparation. 


Algorithm 

Property 

Satis : 
Nodes 

lability 

Time 

Model 

Nodes 

Checking 

Time 

IE2KEQI 

Safety 

1514 

18.67 

1189 

5.61 

Xi,n = 4 

Liveness 

2423 

78.94 

2566 

8.75 

X\ , n =4 

Com Liveness 

2171 

78.39 

3493 

55.08 

X\ , n = 5 

Safety 

6752 

113.37 



X\ , n = 5 

Liveness 

10289 

582.03 



Xi,n = 5 

Com Liveness 

9587 

560.51 



X \ , n = 6 

Safety 


698.46 



Xi , n = 6 

Liveness 


8125.0 



Xi,n = 6 

Com Liveness 

79436 

7616.0 



X 2 ,n = 4 


4598 

214.46 

3429 

50.49 

X 2 ,n = 4 

Liveness 

6824 

885.02 

7541 

69.53 

X 2 ,n = 5 

Safety 

23012 

2106.17 



X.2 ) Tl = 5 

Liveness 

73330 

19742.0 




7 Conclusions 


The results presented here indicate that model checking for LTL may indeed be imple- 
mented efficiently. 

In [CS89], a distributed implementation of the satisfiability algorithm, provides further 
improvement. 

Our model checker provides the user with 

• The expressive power of Linear Temporal Logic. 

• The ability to check, given two LTL specifications, whether one implies the c*her. 

• Efficiency comparable to the CTL model checker. 
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Appendix 

Algorithm X\ for 2 processes 


DECLARE y : [0. . 1] ; 

INITIALLY y-1 ; 

PROCESS PI 

DECLARE tl : [0. . 1] ; 

INITIALLY tl-0; 

L0 : goto L0; I { tl :■ 0; goto LI; > 

LI : if (tl"0) goto L2; 

if (tl»l) goto L3; 

L2 : tl y; goto LI; 

// L3 - critical section 
L3 : tl y; goto L0; 


PROCESS P2 

DECLARE t2 : [0 . . 1] ; 

INITIALLY t2-0; 

MO : goto MO; | { t2 :» 0; goto Ml; > 

Ml : if (t2-0) goto M2; 

if (t2“l) goto M3; 

M2 : t2 y; goto Ml; 

// M3 - critical section 
M3 : t2 y; goto M0; 


END 
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Algorithm X 3 for 2 processes 


DECLARE y : [0 . . 3] ; 

INITIALLY y-0; 

PROCESS PI 

DECLARE rl: [0. .3] ; tl: [0. . 1] ; 

INITIALLY rl-3; tl-0; 

L0 : goto L0; I { tl :- 1; goto LI; } 

LI : if (rl-3 * (y-0 I y-1)) goto L2; 

if (rl-3 “ "(y-0 I y-1)) goto LI; 
if ("(rl-3)) goto L2; 

L2 : if (“(y-0) “ "(y-1)) {rl:-:y; goto LI;} 

if ( (y-0) 1 (y-1)) {rl:«:y; goto L3;> 

// L3 - critical section 

L3 : { rl :- 3; tl:-0; goto L4; } 

L4 : if (t2-l) {y:-2; goto L0;} 
if (t2-0) { goto L5;} 

L5 : if (tl*l) {y:-l; goto L0;> 
if (tl-0) {y:-0; goto L0;> 

END 


PROCESS P2 

DECLARE r2 : [0 . . 3] ; t2:[0..1]; 

INITIALLY r2-3; t2-0; 

*M0 : goto MO; I { t2 :- 1; goto Ml; } 

Mi : if (r2-3 ‘ (y-0 I y-2)) goto M2; 

if (r2-3 ' "(y-0 I y-2)) goto Ml; 

if ("(r2-3)) goto M2; 
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M2 : if (”(y»0) “ ~(y«2)) {r2:«:y; goto Ml;> 
if ( (y*0) | (y-2)) {r2:«:y; goto M3;> 

// M3 - critical section 

M3 : { r2 := 3; t2:*0; goto M4; } 

M4 : if (tl=l) {y:»l; goto MO;} 
if (tl=0) { goto M5;> 

M5 : if (t2=l) {y:»2; goto MO;} 
if (t2«0) {y:*0; goto MO;} 

END 
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